insightwatchのセキュリティチェックでオールグリーンを目指す（その3: CISベンチマーク モニタリング編）

オペレーション部　江口です。今日で入社ちょうど1ヶ月を迎えました。早いものですね。 今のところブログの投稿は週一度以上のペースでやれているので、今後もこのペースで続けていきたいものです。

さて、「insightwatchのセキュリティチェックでオールグリーンを目指す」シリーズの第3回です。

第1回：

insightwatchのセキュリティチェックでオールグリーンを目指す（その1: CISベンチマーク IAM設定編）

第2回：

insightwatchのセキュリティチェックでオールグリーンを目指す（その2: CISベンチマーク ロギング編）

今回は「CIS 3. Monitoring」の対処を行なっていきます。

最初のチェック結果

このパートの最初の結果は以下の通りです。14項目中注意5・重要9の指摘がありました。「正常」だった項目が0!ということで結果が真っ赤っ赤です。

道のり長いな・・・と思いましたが、実は速攻で対処できました。以下その解説です。

指摘事項への対処

この「CIS 3. Monitoring」の要件は以下のように、各種問題についてのアラームの設定となります。 具体的には、CloudTrailの情報をもとに、それを受け取るCloudWatch側にアラームを設定する形です。

• 3.1 許可されていないAPIコールに対して、アラーム通知設定されていること
• 3.2 MFAなしでのAWSマネージメントコンソールログインに対して、アラーム通知設定されていること
• 3.3 rootアカウントの利用に対して、アラーム通知設定されていること
• 3.4 IAMポリシーの変更に対して、アラーム通知設定されていること
• 3.5 CloudTrail設定の変更に対して、アラーム通知設定されていること
• 3.6 AWSマネージメントコンソールのログイン失敗に対して、アラーム通知設定されていること
• 3.7 KMSマスターキーの無効化またはスケジュール削除に対して、アラーム通知設定されていること
• 3.8 S3バケットポリシー変更に対して、アラーム通知設定されていること
• 3.9 AWS Config変更に対して、アラーム通知設定されていること
• 3.10 セキュリティグループ変更に対して、アラーム通知設定されていること
• 3.11 ネットワークACL変更に対して、アラーム通知設定されていること
• 3.12 インターネットゲートウェイ変更に対して、アラーム通知設定されていること
• 3.13 ルートテーブル変更に対して、アラーム通知設定されていること
• 3.14 VPC変更に対して、アラーム通知設定されていること

なかなかのボリュームですが、なんとクラスメソッドメンバーズご利用のお客様にはこれらの設定を一気に行うCloudFormationテンプレートが提供されているのです。すごい！便利！加入しなきゃ！（ダイマ）

このテンプレートの利用の仕方については下記insightwatchユーザーガイドに記載されています。

CIS 3 Monitoringに関する設定（クラスメソッドメンバーズ限定）

ということで、これを利用してデプロイを行いました。

以下、実行に当たっての注意点・補足です。

• チェック結果では各要件に対して全リージョンで設定が必要のように見えます（スクリーンショットを撮り忘れましたが、対応が必要な箇所として全リージョンがリストされます）。ただ、前掲のinsightwatchユーザーガイドでも説明されていますが、クラスメソッドメンバーズをご利用されている場合は全リージョン対応のCloudTrailを東京リージョンに作成しています。このため、東京リージョンでCloudFormationテンプレートのデプロイを行えば良いです。前回使用したCloudFormation StackSetsを利用する必要はありません。

• テンプレートでIAMロールの作成、LambdaやSNSの作成、CloudWatchの設定追加等を行いますので、CloudFormationを実行するIAMロールにはこれらの適切な権限が必要です。私の環境の場合、普段コンソール操作に利用しているユーザについてはCIS1.X対応（参照：第一回）の際にIAMロール作成の権限を削除しているので、適切な権限を持つIAMロールを別途用意しました。

ハマったこと

このCloudFormationテンプレートのデプロイ直後、再度insightwatchでのチェックを行なって見ると、確かにCIS 3.Xの指摘は全てクリアしました。すばらしい。

しかし、結果を確認すると、前回（第二回）解消したはずの「CIS 2.8 KMSマスターキーがローテーション設定されていること」の指摘が再発していました。

指摘されているKMSのキーを確認すると、これはAWS側の管理する（＝AWSマネージド型）Lambdaがデフォルトで環境変数の暗号化に使用するキーでした。 CloudFormationテンプレートでLambdaをデプロイした際、自動的に作成されたもののようです。

しかしAWSマネージド型キーはローテーション設定をユーザ側では変えられないはず。

これはこちらの対処の仕様がない、詰んだのでは・・・と思ったのですが、一つ疑問が湧きました。

というのも、私の環境でAWSマネージド型のキーは他にもいくつか以前に作成したものが存在します。

けれども指摘されているのはこの新しく作成されたLambda用のキーだけ。

なぜだろう、と思って、以下のようなキーのローテーション設定を確認するコマンドを投げてみました。

aws kms get-key-rotation-status --key-id [Key ID]

Lambda用のキーは確かにKeyRotationEnabledの値がfalse、すなわちローテーションされていない、という結果が返ってきます。

$ aws kms get-key-rotation-status --key-id XXXXXX
{
"KeyRotationEnabled": false
}

しかし他のAWSマネージド型のキーの設定を同じコマンドで調べてみると、KeyRotationEnabledの値としてtrueが返ってきました。

・・・これ、もしかして時間が経つと勝手にローテーションが有効になるのか？

というわけで、一晩おいて見たところ・・・

Lambda用のキーでもローテーションが有効になってました。

改めてinsightwatchでチェックすると、無事CIS2.8の指摘も消えていました。

なかなか奥が深い（？）ですね・・・

ここまでの結果

というわけで若干トラブルはありましたが、ともかくここまでの対処で、「CIS 3. Monitoring」の結果はすべて「正常」となりました。

全体の指摘数は下記の通り。注意2・重要17、指摘の合計は19個となりました。だいぶ減ってきましたね！

推移をグラフにすると以下のような感じです。

このペースなら後2、3回で終わりそうだけども、はたしてそううまく行くかどうか。まあ頑張りたいと思います。

以上、「insightwatchのセキュリティチェックでオールグリーンを目指す」シリーズの第3回でした。